Access control for data and information contained in databases is of increasing importance for reasons relating to security and privacy. In a database management system (DBMS), data is stored in data containers made up of records having one or more data fields. In a relational database management system, the data container is a relational object made up of rows and columns wherein each row represents a record and the columns are fields in those records. A relational object may be, for example, a relational table or relational view.
Fine-grained access control (FGAC) has grown in importance to commercial and government users of relational databases especially with recent government initiatives to increase overall security. FGAC is typically defined as the ability to control the access to data by any user at the object level and lower levels. For example, FGAC can be used to limit user access to a specific set of rows in a relational table. This level of access control is desirable for all areas of relational data access such as utilities, but is particularly desirable for data manipulation language (DML) SQL statements such as SELECT, INSERT, UPDATE and DELETE.
Traditional methods of implementing FGAC within relational databases have relied upon the use of views. A view is a logical table which is derived from existing tables and can be queried by users in the same manner as a regular table. A view is defined by metadata known as a view definition. The view definition contains mappings to one or more columns in one or more tables stored on a database. Typically, the view definition is provided a priori by the user of the database in the format of a CREATE VIEW SQL statement.
Views provide one method for implementing FGAC that works well when the number of different restrictions is few or the granularity of the restrictions is such that it affects large, easily identified groups of users. When these conditions are not true, a number of issues arise with the use of views including: (1) view definitions may become quite complex in an effort to contain all the restrictions in one view, straining system limits and making maintenance of the view difficult; (2) if a large number of simple views is desired, each one implementing a unique view of a table based on the restrictions for a specific set of users, the routing of user requests becomes difficult with the solution often being resolved within the database application instead of the DBMS; and (3) if a user can bypass the view when accessing data, for example by having direct access to the underlying tables for query access, then restrictions may be not enforced.
Another known implementation of FGAC uses context attributes of a user session to modify SQL statements by adding a predicate into the query. A predicate is a condition that must be satisfied for the DBMS to return a value. In this approach, the context attributes of a user session (e.g. user identifier) are compared against a security policy defined within a procedure provided by the user on a table or view to make decisions regarding access to data. This approach allows row restrictions traditionally handled by views to be dynamically added to queries without requiring application modification, however this approach has several disadvantages. Firstly, this approach requires user programming of a strictly defined “predicate producing” procedure in order to implement a security policy. The creation of user defined procedures for each policy is time consuming and error prone. Secondly, this approach does not provide access control at the column level. Thirdly, this approach interferes with dynamic SQL caching because the modified SQL statement will no longer match the original text from the request which makes statement matching problematic and thus, has an impact on the performance benefits of the caching. Cached SQL statements can not generally be shared because the result of the security policy applicable to cached statements (i.e. the predicate to be added to the query) is not known in advance.
Users of modern relational databases desire the following capabilities in an FGAC implementation:
(1) an implementation which solves the problem within the DBMS without application changes or application awareness of the implementation;
(2) a pervasive implementation that ensures that all users of the table being controlled are affected, regardless of how the table is accessed;
(3) an implementation that minimizes the complexity and maintenance of the fine-grained access control policies defined by the user;
(4) the ability to apply the implementation to both tables and views;
(5) the ability to control access to rows as well as columns as desired; and
(6) the ability to have unlimited granularity control within the implementation.
In view of the shortcomings of known FGAC implementations, there exists a need for an improved method of implementing fine-grained access control to a database.